In response to this:

Migrate the telemeter-client configmap settings to a CRD field within
ClusterMonitoringSpec in config/v1alpha1. The new TelemeterClientConfig
struct supports:

• nodeSelector: pod scheduling to specific nodes
• resources: compute resource requests and limits
• tolerations: pod tolerations for scheduling
• topologySpreadConstraints: pod distribution across topology domains

Signed-off-by: Daniel Mellado dmellado@fedoraproject.org

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Walkthrough

A new optional TelemeterClientConfig field was added to ClusterMonitoringSpec, defining nodeSelector, resources, tolerations, and topologySpreadConstraints with schema validations. The CRD was extended to include telemeterClientConfig. Several existing list validations were tightened by lowering multiple maxItems values from 10 to 5. Test coverage was expanded to validate creation, duplicate/empty/too-many-item errors, and update-path behaviors for TelemeterClientConfig.

❌ Failed checks (1 warning)

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• Generate coding plan for human review comments

• Add TelemeterClientConfig struct to ClusterMonitoringSpec API
• Support pod scheduling via nodeSelector, tolerations, and topologySpreadConstraints
• Enable resource management with resources field for CPU/memory constraints
• Include comprehensive validation rules and test coverage for new configuration

Define TelemeterClientConfig struct with pod scheduling fields

• Added TelemeterClientConfig field to ClusterMonitoringSpec struct with comprehensive
 documentation
• Defined new TelemeterClientConfig type with four configuration fields: nodeSelector,
 resources, tolerations, and topologySpreadConstraints
• Implemented validation constraints including minProperties: 1, minItems: 1, and maxItems: 10
 for list fields
• Added detailed comments explaining each field's purpose, defaults, and constraints

config/v1alpha1/types_cluster_monitoring.go

Generate deepcopy methods for TelemeterClientConfig

• Added DeepCopyInto method for TelemeterClientConfig with proper handling of map and slice
 fields
• Added DeepCopy method for TelemeterClientConfig to support object cloning
• Implemented deep copy logic for nodeSelector map, resources slice, tolerations slice, and
 topologySpreadConstraints slice

config/v1alpha1/zz_generated.deepcopy.go

Generate swagger documentation for TelemeterClientConfig

• Added swagger documentation map for TelemeterClientConfig struct
• Documented all four configuration fields with detailed descriptions of their purpose and
 constraints
• Included information about default values and validation rules in swagger documentation

config/v1alpha1/zz_generated.swagger_doc_generated.go

Description

TelemeterClientConfig has +kubebuilder:validation:MinProperties=1, but the type comment does not
document that the object must not be empty (i.e., at least one field must be set). This violates the
requirement that validation markers be fully documented, potentially confusing API consumers about
valid/invalid configurations.

Code

config/v1alpha1/types_cluster_monitoring.go[R575-581]

+// TelemeterClientConfig provides configuration options for the Telemeter Client component
+// that runs in the `openshift-monitoring` namespace. The Telemeter Client collects selected
+// monitoring metrics and forwards them to Red Hat for telemetry purposes.
+// Use this configuration to control pod scheduling and resource allocation.
+// +kubebuilder:validation:MinProperties=1
+type TelemeterClientConfig struct {
+	// nodeSelector defines the nodes on which the Pods are scheduled.

Evidence

PR Compliance ID 6 requires that every validation marker be documented in the field/type comments.
The new TelemeterClientConfig type adds +kubebuilder:validation:MinProperties=1 but its comment
only describes purpose/scheduling/resources and does not state that at least one property must be
set (non-empty object requirement).

AGENTS.md
config/v1alpha1/types_cluster_monitoring.go[575-581]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`TelemeterClientConfig` includes the validation marker `+kubebuilder:validation:MinProperties=1`, but the type-level comment does not document the resulting constraint that the object must not be empty.

## Issue Context
Compliance requires that every validation marker applied to an API field/type be fully documented in comments so users understand constraints without inspecting generated schema.

## Fix Focus Areas
- config/v1alpha1/types_cluster_monitoring.go[575-581]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The CRD schema for spec.telemeterClientConfig.topologySpreadConstraints documents constraints (e.g.,
maxSkew “0 is not allowed” and specific allowed values for whenUnsatisfiable) but does not encode
them as OpenAPI validations, so the API can accept values that contradict the schema’s own
documented rules.

Code

config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yaml[R2178-2274]

+                        maxSkew:
+                          description: |-
+                            MaxSkew describes the degree to which pods may be unevenly distributed.
+                            When `whenUnsatisfiable=DoNotSchedule`, it is the maximum permitted difference
+                            between the number of matching pods in the target topology and the global minimum.
+                            The global minimum is the minimum number of matching pods in an eligible domain
+                            or zero if the number of eligible domains is less than MinDomains.
+                            For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same
+                            labelSelector spread as 2/2/1:
+                            In this case, the global minimum is 1.
+                            | zone1 | zone2 | zone3 |
+                            |  P P  |  P P  |   P   |
+                            - if MaxSkew is 1, incoming pod can only be scheduled to zone3 to become 2/2/2;
+                            scheduling it onto zone1(zone2) would make the ActualSkew(3-1) on zone1(zone2)
+                            violate MaxSkew(1).
+                            - if MaxSkew is 2, incoming pod can be scheduled onto any zone.
+                            When `whenUnsatisfiable=ScheduleAnyway`, it is used to give higher precedence
+                            to topologies that satisfy it.
+                            It's a required field. Default value is 1 and 0 is not allowed.
+                          format: int32
+                          type: integer
+                        minDomains:
+                          description: |-
+                            MinDomains indicates a minimum number of eligible domains.
+                            When the number of eligible domains with matching topology keys is less than minDomains,
+                            Pod Topology Spread treats "global minimum" as 0, and then the calculation of Skew is performed.
+                            And when the number of eligible domains with matching topology keys equals or greater than minDomains,
+                            this value has no effect on scheduling.
+                            As a result, when the number of eligible domains is less than minDomains,
+                            scheduler won't schedule more than maxSkew Pods to those domains.
+                            If value is nil, the constraint behaves as if MinDomains is equal to 1.
+                            Valid values are integers greater than 0.
+                            When value is not nil, WhenUnsatisfiable must be DoNotSchedule.
+
+                            For example, in a 3-zone cluster, MaxSkew is set to 2, MinDomains is set to 5 and pods with the same
+                            labelSelector spread as 2/2/2:
+                            | zone1 | zone2 | zone3 |
+                            |  P P  |  P P  |  P P  |
+                            The number of domains is less than 5(MinDomains), so "global minimum" is treated as 0.
+                            In this situation, new pod with the same labelSelector cannot be scheduled,
+                            because computed skew will be 3(3 - 0) if new Pod is scheduled to any of the three zones,
+                            it will violate MaxSkew.
+                          format: int32
+                          type: integer
+                        nodeAffinityPolicy:
+                          description: |-
+                            NodeAffinityPolicy indicates how we will treat Pod's nodeAffinity/nodeSelector
+                            when calculating pod topology spread skew. Options are:
+                            - Honor: only nodes matching nodeAffinity/nodeSelector are included in the calculations.
+                            - Ignore: nodeAffinity/nodeSelector are ignored. All nodes are included in the calculations.
+
+                            If this value is nil, the behavior is equivalent to the Honor policy.
+                          type: string
+                        nodeTaintsPolicy:
+                          description: |-
+                            NodeTaintsPolicy indicates how we will treat node taints when calculating
+                            pod topology spread skew. Options are:
+                            - Honor: nodes without taints, along with tainted nodes for which the incoming pod
+                            has a toleration, are included.
+                            - Ignore: node taints are ignored. All nodes are included.
+
+                            If this value is nil, the behavior is equivalent to the Ignore policy.
+                          type: string
+                        topologyKey:
+                          description: |-
+                            TopologyKey is the key of node labels. Nodes that have a label with this key
+                            and identical values are considered to be in the same topology.
+                            We consider each <key, value> as a "bucket", and try to put balanced number
+                            of pods into each bucket.
+                            We define a domain as a particular instance of a topology.
+                            Also, we define an eligible domain as a domain whose nodes meet the requirements of
+                            nodeAffinityPolicy and nodeTaintsPolicy.
+                            e.g. If TopologyKey is "kubernetes.io/hostname", each Node is a domain of that topology.
+                            And, if TopologyKey is "topology.kubernetes.io/zone", each zone is a domain of that topology.
+                            It's a required field.
+                          type: string
+                        whenUnsatisfiable:
+                          description: |-
+                            WhenUnsatisfiable indicates how to deal with a pod if it doesn't satisfy
+                            the spread constraint.
+                            - DoNotSchedule (default) tells the scheduler not to schedule it.
+                            - ScheduleAnyway tells the scheduler to schedule the pod in any location,
+                              but giving higher precedence to topologies that would help reduce the
+                              skew.
+                            A constraint is considered "Unsatisfiable" for an incoming pod
+                            if and only if every possible node assignment for that pod would violate
+                            "MaxSkew" on some topology.
+                            For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same
+                            labelSelector spread as 3/1/1:
+                            | zone1 | zone2 | zone3 |
+                            | P P P |   P   |   P   |
+                            If WhenUnsatisfiable is set to DoNotSchedule, incoming pod can only be scheduled
+                            to zone2(zone3) to become 3/2/1(3/1/2) as ActualSkew(2-1) on zone2(zone3) satisfies
+                            MaxSkew(1). In other words, the cluster can still be imbalanced, but scheduler
+                            won't make it *more* imbalanced.
+                            It's a required field.
+                          type: string

Evidence

In the generated CRD manifest, maxSkew is only typed as an integer (no minimum constraint) even
though its description states “0 is not allowed”, and whenUnsatisfiable is only typed as a string
(no enum constraint) despite its description listing specific allowed values. The API type comment
states this field maps directly to the Pod spec field, so having the CRD accept values outside the
documented constraints undermines the API contract and shifts validation burden to later
stages/consumers.

config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yaml[2178-2199]
config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yaml[2254-2274]
config/v1alpha1/types_cluster_monitoring.go[628-646]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The generated CRD schema for `spec.telemeterClientConfig.topologySpreadConstraints` documents constraints (e.g., `maxSkew` “0 is not allowed” and specific allowed values for `whenUnsatisfiable`) but does not enforce them via OpenAPI/CEL validations.

### Issue Context
This means the API server may accept values that contradict the schema’s own documented rules, leaving validation to later consumers.

### Fix Focus Areas
- config/v1alpha1/types_cluster_monitoring.go[628-646]
- config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml[624-832]
- config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yaml[2095-2287]

### Implementation notes
- Add `+kubebuilder:validation:XValidation` rules on `TopologySpreadConstraints` to enforce:
 - `maxSkew > 0` for every element
 - `whenUnsatisfiable` is one of `DoNotSchedule` / `ScheduleAnyway`
- Add a CRD schema test case that attempts to create a resource with `maxSkew: 0` and/or an invalid `whenUnsatisfiable` and asserts the expected admission error substring.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.